Message oriented middleware (MOM) supports asynchronous communication between applications through queues. A producing application (program) can send (PUT) a message to a named queue from which a consuming application can receive (GET) the message.
The process is asynchronous in that the MOM takes responsibility for the message between the sending application's PUT and the consuming application's GET. Thus, the sending application can complete successfully even if the receiving application is unavailable, perhaps not running, and later the receiving application can GET the message even if the sending application is no longer available.
In a network of computers, the MOM permits an application running in one computer, the local computer, to send a message to a queue that resides in a different computer, the remote computer.
FIG. 1 provides an example of such a messaging system. A program 20 PUTs a message to a “holding” queue 40 on sending or source queue manager 30 at local computer 10. This queue is called the transmit queue.
At an appropriate time, that is, at least when the MOM is operational on the remote computer and the communication link or channel to that computer is operational, the queue manager transfers the message from the local computer to remote computer 85 over channel 70 using mover sending software 50.
Mover receiving software 60 on receiving or destination queue manager 90 at the remote computer 85 receives the message and adds the message to the actual target or receive queue 80.
When program 20 issue its PUT or PUTs to the remote queue within a transaction, the queue manager 30 in the local computer adds the message to the transmit queue 40 within that transaction. It does not transfer the message or messages to the remote computer 85 until program 20 commits its transaction. The messages on transmit queue 40 do not become visible to the mover sending software 50 until program 20 has committed the transaction containing those messages.
A consequence of this is that all messages PUT within a transaction are held until commit time, and then all become available for transmission simultaneously. This has at least the following drawbacks:
i) Latency: If a transaction emits a number of messages then transmission will not start for any of the messages until the transaction commits. This equates to T+N+M, where T is the time when the application issues the PUT, which may be after when the transaction has started; N is the time interval between the PUT and the COMMIT; and M is the time taken to transmit the message.
ii) Unequal load: The transmission load imposed by a transaction is unequal in the sense that there are relatively large gaps pending transaction completion, followed by relatively large clumps of the messages in the transaction. This pattern of use is known to reduce the effective throughput of the communication link to the detriment of all traffic on that link.
Publication “Controlled optimistic processing, especially in a message system” disclosed by IBM on 16 Sep. 2002 (at priorart.ip.com—IPCOM000016201D) discloses a solution enabling the reading of uncommitted messages or other resources.
U.S. Pat. No. 4,665,520 discloses a system which may perform optimistic commitments of messages by sending uncommitted messages out. The database at the other end will be designed to run a transaction and to wait for a final signal to commit or abort. Additionally commit or abort signals are provided whenever a particular output message becomes committable or is recognized to be an orphan message.
The problem with the solution of the U.S. Pat. No. 4,665,520 is that the database has to be designed to cope with the situation in which its optimistic processing of a transaction is not valid. In other words the database must be able to back out of the transaction upon request. Thus the processing of the database is changed.